1. Field of the Invention
Methods and apparatuses consistent with the present invention relate to a virtual machine, and more particularly, to providing a partially-isolated execution environment for multiple applications that allows multiple applications to be stably executed in a virtual machine to be executed by a single operating system (OS) process, and to a digital information apparatus using the same.
2. Description of the Related Art
In general, a virtual machine to be executed in a single OS process (for example, middleware) is loaded in an environment where only one application can be executed. Then, when multiple applications are executed under this environment, a structure that allows Java objects and resources of the OS to be shared among all applications needs to be provided. Accordingly, if the shared Java object is corrected by one application, other applications may be affected by the correction. In a related art virtual machine, a basic isolation function is provided such that static fields included in classes loaded by different class loaders are separately managed, not shared. However, an isolated execution environment for a group of threads is not provided.
A method of providing an isolated execution application is broadly divided into two methods: a method of executing each application in one OS process; and a method of executing multiple applications in one OS process under an isolated environment. The invention refers to the second method, and relates to a technology of providing partial isolation to partially allow sharing of objects.
A virtual machine provides a standard application execution environment that ensures mobility of an application to be executed in any digital information apparatus. FIG. 1 is a diagram showing the configuration of a digital information apparatus including a virtual machine according to the related art.
Referring to FIG. 1, a digital information apparatus 100 includes a Central Processing Unit (CPU) 10, a memory in which a virtual machine 20, middleware 30, and downloaded application 40 reside, a display processor 50, an external apparatus communication unit (peripherals) 60, and a bus 70. The external apparatus communication unit 60 may include a Universal Serial Bus (USB) connection device, a serial connection device, an infrared (IR) connection device, a flash memory, an Ethernet communication device, a hard disk, and the like. The Ethernet communication may be implemented by various shapes, for example, a wired packet communication network, such as Local Area Network (LAN) or Wide Area Network (WAN) through Asymmetric Digital Subscriber Line (ADSL)/cable modem, wireless/mobile communication network, such as wireless LAN, Code Division Multiple Access (CDMA)/Global System for Mobile Communications (GSM)/General Packet Radio Services (GPRS), or wired/wireless broadcast network, such as digital TV public/cable/satellite. In case of satellite broadcast or public broadcast, the digital information apparatus 100 may be connected to LAN or ADSL through IEEE 1394 or an Ethernet interface. In case of cable broadcast, since bidirectional communication support is executed through a cable modem, bidirectional communication can be supported without using a separate Ethernet interface. Further, for a Personal Video Recorder (PVR) function, a hard disk using an interface, such as Enhanced Integrated Device Electronics (EIDE), may be included.
In case of a virtual machine 20 that is mounted on the digital information apparatus 100 connected to a network, virtual machine applications are usually downloaded from the outside and then executed. In the memory, the downloaded applications 40, and the middleware 30 for managing a life cycle, such as the start and end of the application, reside. The middleware 30 and the downloaded applications 40 are executed on the virtual machine 20. For example, in case of an information apparatus, such as a digital TV (DTV) or a digital set-top box having a data broadcast receiving function, a Java virtual machine is mounted, and DTV middleware (based on a standard specification, such as OpenCable Application Platform (OCAP)/Advanced Common Application Platform (ACAP)/Multimedia Home Platform (MHP)) for controlling DTV apparatuses and managing downloaded Java applications exists thereon. The Java applications to be executed in such an information apparatus are created based on the Java specification called Xlet and are downloaded through a broadcast or a network.
Meanwhile, the virtual machine applications are formed in terms of classes. One application may include multiple classes. In each class, methods including execution codes are included. Each method has execution commands expressed as byte codes. There are various kinds of virtual machines. Among these, virtual machines, such as “Common Language Runtime (CLR)” introduced by Java and Microsoft and “Smalltalk”, are representative. For convenience of explanation, in the invention, the description will be given by way of the Java virtual machine. However, the scope of the invention is not limited to a specified virtual machine.
FIG. 2 is a diagram showing the configuration of the Java virtual machine according to the related art. Referring to FIG. 2, the Java virtual machine 20 has a class library 21 and a run-time system.
The class library 21 is a set of common classes to be executed on the run-time system, and means a set of classes that are formed in advance to be used in the application.
The run-time system provides the overall execution environment that can execute virtual machine codes. The run-time system internally includes an interpreter 23, a JIT compiler 22, a class loader 24, a garbage collector 26, and a thread manager 25.
The JIT compiler 22 converts virtual machine commands into a machine language of the CPU during execution of classes. In general, a Just-In-Time (JIT) compiler is used. The interpreter 23 executes the execution codes of the classes. That is, the interpreter 23 recognizes the virtual machine commands and executes the commands. The class loader 24 loads the classes. The thread manager 25 manages threads as an execution unit. Specifically, the thread manager 25 collectively manages multiple threads to be simultaneously executed in order to process different codes. The garbage collector 26 manages memory spaces of objects and collects objects unused such that the memory spaces are reused.
FIG. 3 is a diagram showing the correlation of thread groups and threads in the Java virtual machine shown in FIG. 2. In case of the Java virtual machine 20, thread groups for grouping associated threads exist. In this case, each thread belongs to one thread group. The thread group belongs to another thread group. When the Java virtual machine 20 is executed, a main thread group and a finalizer thread exist below a system thread group, and a main thread exist in the main thread group. The main thread executes a “main” method transferred to a parameter when the virtual machine is driven, and the finalizer thread executes a required cleanup job before the objects are collected.
FIG. 4 is a diagram showing a flow of an execution process of the Java virtual machine according to the related art. Generally, one Java virtual machine is driven by one OS process. A description will be given for FIG. 4 on the above-described condition.
When the Java virtual machine 20 is driven, basic global data structures are initialized, and then the class loader 24 is initialized (operation S10). Next, a system thread group and a finalizer thread belonging to the system thread group are generated, and a main thread group and a main thread belonging to the main thread group are generated (operation S20). At this time, the generated finalizer thread and main thread are registered in a thread manager to be then managed (operation S30). Next, the main class is loaded and initialized (operation S40). Here, a method of loading a main class is assigned by a parameter when the virtual machine is driven. If the main class is loaded, a main method is executed. In the digital information apparatus 100 shown in FIG. 1, a class including start codes of the middleware 30 residing in the memory corresponds to the main class. From the main method defined in the main class, the middleware 30 starts to be driven (operation S50). If the main method ends, operation of ending the virtual machine is executed. At the ending operations, all threads that are being currently executed (threads that are being managed by the thread manager 25) end. Then, the process that is being executed by the virtual machine ends (operation S60).
An execution process of the middleware 30 will be described in detail with reference to FIG. 5. FIG. 5 is a diagram showing a flow of an execution process of the middleware according to the related art. When the middleware 30 starts, the basic data structures are initialized (operation S51), and it is judged which action is to be executed in order to execute the application (operation S52). If a new application needs to be loaded or generated, the class of the application is loaded, and then the objects of the application class are generated (operation S53). When the start of the application is required, a new thread is generated, and the application code is driven by calling the start method of the object (operation S54). Further, when the stop of the application during the execution is required, a stop method for stopping the application is called, and it waits until the application ends (operation S55). If other actions are required, other actions are executed (operation S56). Various actions described above may be repeatedly executed. Then, it is judged whether or not another action is to be executed (operation S57). When another action is to be executed, the process returns to operation S52 and the above-described operations are repeatedly executed. Through the above-described process, it is possible to provide an environment where multiple different applications are simultaneously executed.
However, the above-described related art virtual machine cannot control resources to be shared while multiple applications are executed, and thus stability of the virtual machine may be threatened. Since the virtual machine is executed by one OS process, multiple applications are executed by multiple threads in the same process. The method of ending the application is based on an assumption that the thread executing the application by calling the end method cleans up all threads generated during the execution and all resources used. However, when the application does not actually execute this process, the threads by the application and the resources are not cleaned up. When the state where the resources are not cleaned up is continued, the virtual machine may not operate any more due to lack of the resources.
In order to solve these problems, there is suggested a method that completely isolates different applications as if one application is executed in one OS process. In this case, however, there is a problem in that different applications cannot share any objects. Accordingly, all codes of the middleware for managing applications on the virtual machine are coded again in consideration of a situation where the objects are not shared, an inefficient method, such as Remote method invocation (RMI) or the like, needs to be used when sharing of the objects are required. Therefore, there is a problem in that the middleware depending on the related art virtual machine changes an object management method according to a new method.
Further, there is suggested a method of managing applications like the OS process while allowing sharing of a part of the objects. In this case, however, a special function needs to be used in order to share the objects, and thus a virtual machine different from the standard Java specification needs to be implemented. Further, the application and middleware need to be implemented according to a virtual machine different from the standard.